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The invention provides a method 
and system for correct interoperation of 
multiple diverse file server or file locking 
protocols, using a uniform multi-protocol 
lock management system. A file server 
determines, before allowing any client 
device to access data or to obtain a lock, 
whether that would be inconsistent with 
existing locks, regardless of originating 
client device or originating protocol for 
those existing locks, A first protocol 
enforces mandatory file-open and 
file-locking together with an opportunistic 
file-locking technique, while a second 
protocol lacks file-open semantics and 
provides only for advisory byte-range 
and file locking. Enforcing file-locking 
protects file data against corruption 
by NFS client devices. A CIFS client 
device, upon opening a file, can obtain an 
"oplock" (an opportunistic lock). When a 
client device issues a non-CIFS protocol 
request for the oplocked file, the file 
server sends an oplock-brcak message to 
the CIFS client device, giving the CIFS 
client device the opportunity to flush any 
cached write operations and possibly close 
the file. Allowing NFS and NLM requests 
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to break oplocks ensures that file data remains available to NFS client devices simultaneously widi protecting integrity of that file data. A 
CIFS client device can obtain a "change-monitoring" lock for a directory in the file system, so as to be notified by the file server whenever 
there is a change to that directory. The file server notes changes to the directory by both CIFS and non-CIFS client devices, and notifies 
those CIFS client devices with "change-monitoring" locks of those changes. 



Codes used to identify States party to the PCX on the front 



FOR THE PURPOSES OF INFORMATION ONLY 

pages of pamphlets publishing international applications under the PCT. 



AL Albania 

AM Armenia 

AT Austria 

AU Australia 

AZ Azerbaijan 

BA Bosnia and Heraegovina 

BB Barbados 

BE Belgium 

BF Buricina Faso 

BG Bulgaria 

BJ Benia 

BR Brazil 

BY Belarus 

CA Canada 

CF Central African Republic 

CG - Congo 

CH Switzerland 

CI cote d'lvoirc 

CM Cameroon 

CN China 

CU Cuba 

CZ Czech Rcpablic 

DE Geitnany 

DK DcmtiaA 

BE Estonia 



n 

FR 

GA 

GB 

GE 

GH 

GN 

GR 

HU 

IE 

IL 

IS 

IT 

JP 

K£ 

KG 

KP 

KR 
KZ 
LC 
U 
LK 
LR 



Spain 
Fmland 
France 
Gabon 

United Kingdom 

Georgia 

Ghana 

Guinea 

Greece 

Hungary 

Ireland 

Israel 

Iceland 

Italy 

Japan 

Kenya 

Kyrgyzstan 

Democratic People** 

RcpuWic of Korea 

Rqwblic of Korea 

Kazakstan 

Saint Lucia 

Liechtenstein 

SriLanlca 

Liberia 



LS 

LT 

LU 

LV 

MC 

MD 

MG 

MK 

ML 
MN 
MR 
MW 
MX 
NE 
NL 
NO 
NZ 
PL 
PT 
RO 
RU 
SD 
SE 
SG 



Lesotho 

Lithuania 

Luxembourg 

Latvia 

Monaco 

Republic of Moldova 

Madagascar 

The former Yugoslav 

Republic of Macedonia 

Mali 

Mongolia 

Mauritania 

Malawi 

Mexico 

Niger 

Netherlands 

Norway 

New Zealand 

Poland 

Portugal 

Romania 

Russian Federation 

Sudan 

Sweden 

Sing^re 



SI 


Slov^ia 


SK 


Slovakia 


SN 


Senegal 


sz 


Swaziland 


TD 


Chad 


TG 


Togo 


TJ 


Tajikistan 


TM 


Turkmenistan 


TR 


Ttokey 


TT 


THnidad and Tobago 


UA 


Uknune 


VG 


Uganda 


US 


United States of America 


uz 


Uzbekistan 


VN 


Vict Nam 


YU 


Yugoslavia 


zw 


Zimbabwe 



wo 99/30254 



PCT/US98/25388 



Title of the Invention 
Multi-Protocol Unified File-locking 
Background of the Invention 

1 . Field of the Invention 

The invention relates to locking in a multi-protocol file server. 

2. Related Art 

In an integrated computer network, it is desirable for multiple client devices to 
share files. One known method is to provide a network file server for storing files, capable of 
receiving and responding to file server requests from those client devices. These file server 
requests are made using a file server protocol, which is recognized and adhered to by both the 
file server and the client device. Because the files are stored at the file server, multiple client 
devices have the opportunity to share simultaneous access to files. 

One problem in the art is that there are multiple diverse file server protocols, each 
with diflfering semantics for file operations. It is known to provide a single file server that 
recognizes multiple file server protocols, but there is a particular difficulty in that many file 
server protocols have differing and incompatible semantics for file locking and file sharing. 
Incompatible locking semantics presents a hurdle in providing a single file system to multiple 
diverse client devices. If a first client device relies on a first file server protocol (having first 
file-locking semantics), a second client device using a second file server protocol (having 
different file-locking semantics) can cause applications at that first client device to fail 
catastrophically. Thus, correct operation of each file server protocol relies on conformity with 
its file-locking semantics by all other file server protocols. 

For example, one protocol commonly used for devices using the Unix operating 
system (or a variant thereof) is the NFS ("Network File System") protocol. Devices using the 
Windows operating system (or a variant thereoO can also use the NFS protocol by means of the 
"PC NFS" implementation. The NFS protocol is designed to be stateless, and so does not 
provide any semantics for files to be locked against sharing or otherwise restricted to a single 
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lock, whether that would be inconsistent with existing locks, regardless of originating client 
device and regardless of originating file server protocol or file-locking protocol for those 
existing locks. In the case of CIFS client devices attempting to read or write data, the file server 
performs this check when the client device opens the file. In the case of CIFS client devices 
5 requesting a byte-range lock, the file server performs this check when the client device requests 
the byte-range lock. In the case of NFS client devices, the file server performs this check when 
the client device actually issues the read or vmte request, or when the NFS client device requests 
an NLM byte-range lock indicating intent to read or write that byte range. Enforcing file- 
locking semantics protects file data against corruption by NFS client devices. 

10 

In a second aspect of the invention, a CIFS client device, upon opening a file, can 
obtain an "oplock" (opportunistic lock), an exclusive file lock that permits only that one client to 
read or write the file. When a client device issues a non-CIFS (that is, NFS or NLM) protocol 
request for the oplocked file, the file server sends an oplock-break message to the CIFS client 
15 device, giving the CIFS client device the opportunity to flush any cached write operations and 
possibly close the file. Allowing NFS and NLM requests to break oplocks ensures that file data 
remains available to NFS client devices simultaneously with protecting integrity of that file data. 

In a third aspect of the invention, a CIFS client device can obtain a "change- 
20 monitoring" lock for a directory in the file system, so as to be notified by the file server 
whenever there is a change to that directory. (Changes to a directory include creating, deleting 
or renaming files within that directory, or moving files into or out of that directory.) The file 
server notes changes to the directory by both CIFS client devices and non-CIFS client devices, 
and notifies those CIFS client devices with "change-monitoring" locks of those changes. 

25 

Brief Description of the Drawings 
Figure I shows a first block diagram of a system including a multi-protocol file 

server. 

30 

Figure 2 shows a second block diagram of a system including a multi-protocol 

file server. 

Figure 3 shows a process flow diagram of a method of operating a multi-protocol 

35 file server 
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Figure 4 shows a process flow diagram of a method of operating a cross-protocol . 
lock manager in a multi-protocol file server. 

Figure 5 shows a process flow diagram of a method of operating an oplock 
manager in a multi-protocol file server. 

Figure 6 shows a process flow diagram of a meti^od of operating a change-notify 
manager in a multi-protocol file server. 

p^*.i\.A n^^rription of th° Pr.ferr>.H Fmbodimcnt 

In the following description, a preferred embodiment of tite invention is described 
witit regard to preferred process steps and data structures. Tl.ose silled in the art would 
.eco^ze after perus^ofti^is application that embodiments ofthe invention can be tmplemen^^ 

usinrseneral purpose processors or special purpose processors or oti.er circmts adapted t 
particular process steps and data stmctures described herein, and ti.at implementauon of the 
process steps and data structures described herein would not require undue expenmentation or 
further invention. 

System Architecture (Client/Server) 

Figure 1 shows a first block diagram of a system including a multi-protocol file 

server. 

A system 100 includes a file server 1 10, a computer network 120, and a plurality 
of client devices 130. 

•me file server 1 10 includes a processor 1 1 1 ai,d mass storage 1 12. The mass 
^e H2 is capable of s»H„g ^ rerteving a se, of files ,13 having da» fo, 
. reideval. ne prccessor U. is capable of receiving a sequence of ,.,»es, messages 12 fiom 
^ 120, parsing^ose messages as and da«. and manipuia«,g *. fi.^ H 

on U>e mass storage 112. and sending response messages, in response ,0 those commands «,d 
data. 
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The file server 1 10 and the client devices 130 are coupled to the network 120 and 
communicate using messages 121 transmitted on the network 120. The messages 121 include 
file system requests transmitted by the client devices 130 to the file server 1 10 and file system 
responses transmitted by the file server 1 10 to the client devices 130. 

5 

System Architecture (File-Locking Semantics) 

Figure 2 shows a second block diagram of a system including a multi-protocol 

file server. 

10 

The system 100 includes the set of client devices 130, including Unix client 
devices 201, PC NFS Windows client devices 202, and CIFS Windows client devices 203. Unix 
client devices 201 execute the Unix operating system and use the Unix/NFS file server protocol. 
PC NFS Windows client devices 202 execute the Windows operating system and use the PC 
15 NFS file server protocol. CIFS Windows client devices 203 execute the Windows operating 
system and use the CIFS file server protocol. 

Unix client devices 201 and PC NFS Windows client devices 202 communicate 
with the file server 1 10 using the NFS file server protocol, which is recognized at the file server 
20 1 10 by an NFS file server protocol parser 211. CIFS Windows client devices 203 communicate 
with the file server 1 10 using the CIFS file server protocol, which is recognized at the file server 
110 by a CIFS file server protocol parser 212. Messages using either the NFS file server 
protocol or the CIFS file server protocol are parsed by the processor 1 1 1 and processed by an 
oplock manager 220. 

25 

The oplock manager 220 manages access to files 113 having CIFS oplocks. Its 
operation is described in further detail with regard to figure 3 and figure 5. The oplock manager 
element 220 is coupled to a cross-protocol lock manager 230. 

30 The cross-protocol lock manager 230 manages the file-locking semantics of the 

file server 110. It processes and records infoimation regarding four types of locks — CIFS byte- 
range locks 241, CIFS file locks 242, PC NFS (NLM) file locks 243, and NLM byte-range locks 
244. Its operation is described in further detail with regard to figure 3 and figure 4. 

3 5 Differing File-Locking Semantics 

5 
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As noted with regard to figure 2. file server request messages 140 can be received 
from Unix client devices 201, PC NFS Windows client devices 202. or CIFS Windows client 
devices 203, and can use the NFS file server protocol or the CIFS file server protocol. In 
addition to each using differing file server protocols, each of these types of client dev.ce 130 has 
a different model of file locking provided by the file server 110. 

In particular, the NFS file sever protocol provides for performing file system 
operations >^dthout any form of file-open or file-close semantics. TTiese NFS file system 
operations can include read or write operations to file data, or file system manipulation (that is, 
read and write operations to directories). File system manipulation can include creating files or 
directories, renaming files or directories, moving files from one directory to another, or 
removing (deleting) files or directories from tlie file system. 

The NLM adjunct protocol provides for obtaining and releasing byte-range locks 
for files These byte-range locks can be "read locks." which induce other compliant applications 
(such as at other client devices 130) to refrain from writing to the specified byte-range. These 
byte-range locks can alternatively be "write locks," which induce other compliant applications to 
refrain from either reading from or writing to the specified byte-range. 

The CIFS file server protocol provides for perfomiing file-open operations, and 
obtaining file locks on the files 1 13 to be opened, before attempting any read or write operations 
to data in those files 113. At file-open time, a CIFS client device 130 can specify the access- 
„.ode it desires (read-only, write-only, or read-write), and the deny-mode it desires to impose on 
other client devices 130 attempting to open the same file 1 13 (deny-none, deny-read, deny-wr.te. 
or deny-all). THereafter, CIFS file system operations need only be checked against the access- 
mode that the file-open obtained. A CIFS client device 130 can also specify a byte-range lock 
for a byte-range in a file the client device 130 holds open. THe byte-range lock is either an 
exclusive lock, also called a "write lock" (having access-mode read-write and deny-mode deny- 
all), or a nonexclusive lock, also called a "read lock" (having access-mode read-only and deny- 
mode deny-write). 

The file server 1 10 determines a lock mode that combines the access-mode and 
the deny-mode. As used herein, the phrase "lock mode" refers to a uniform lock mode imposed 
by the file server 1 10 which combines an access-mode and a deny-mode. 



5 
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At file-open time, CIFS client devices 130 can also obtain an oplock 
(opportunistic lock), which provides that die CIFS client device 130 opening the file has 
exclusive access to the file so long as another client device 130 does not attempt to- use the file. 
The oplock provides a higher degree of exclusivity to the file than strictly necessary for the 
5 client device 130, with the caveat that the exclusivity of the oplock can be broken by attempted 
access by another client device 130. 

The file server 1 10 provides for correct interoperation among client devices 130 
using NFS (with or without the adjunct protocol NLM) or CIFS; To provide for correct 
10 interoperation, the file server 110 provides a uniform file-locking semantics. In a preferred 
embodiment, the uniform file-locking semantics has the following effects: 

The file server 110 prevents Unix client devices 201 from performing NFS write 
operations that would overwrite data in a file 113 that is already opened and in use by a 
15 CIFS client with deny-modes deny- write or deny-all. 

The file server 110 prevents Unix client devices 201 and PC NFS Windows client 
devices 202 from performing NFS file system operations that would remove or rename a 
file 1 13 that is already opened and in use by a CIFS client. 

When a Unix client device 201 or a PC NFS Windows client device 202 makes an NFS 
request to remove, rename, or write data to a file 113 that is oplocked by a CIFS client, 
the file server 1 10 will enforce CIFS oplock semantics for the file 113. The file server 
1 10 sends an oplock-break message 140 to the client device 130 holding the oplock, and 
receives a response from the client device 130. If the client device 130 closes the file 
1 13, the NFS request can proceed and the file server 110 allows it to. 

When a Unix client device 201 or a PC NFS Windows client device 202 makes an NFS 
request to read data firom a file 1 13 that is oplocked by a CIFS client, the file server 110 
will enforce CIFS oplock semantics for the file 113. The file server 1 10 sends an oplock- 
break message 140 to the client device 130 holding the oplock, and receives a response 
fi-om the client device 130. When the client device 130 either closes the file 113 or 
flushes its write cache to the file ser\'er 1 10, the NFS request can proceed and the file 
server 110 allows it to. 
35 

7 



20 



25 



SUBSTITUTE SHEET (RULE 26) 



PCT/US98/2S388 

WO 99/30254 

The file server 110 tests for mutual compatibility for file-open requests from CIFS 
Windows client devices 203, and NLM file lock requests from PC NFS Windows client 
devices 202. with regard to their specified lock modes. The phrase NLM "file lock" is 
used herein in place of the known phrase NLM "share lock." fiirther described in the 
following document: "X/Open CAE Specification: Protocols for X/Open Interworking: 
XNFS, Issue 4 (X/Open Document Number C218), hereby incorporated by reference as 
if fvdly set forth herein. The specified lock mode is determined by the file server llOby 
combining the requested access-mode and deny-mode. 

To provide these effects, the file server 110 performs the following lock 
management operations: 

Upon receiving a CIFS file-open request message 140, the file server 110 tests the file- 
open request for conflict with existing CIFS and NLM file locks, and for conflict w.th 
existing NLM byte-range locks. For the purpose of comparison with newly requested 
file locks, the file server 110 treats existing NLM byte-range locks as having deny-mode 
deny-none, and as having access-mode read-only for nonexclusive locks and access- 
mode read-write for exclusive locks. 

Upon receiving a CIFS byte-range lock request message 140. the file server 1 10 tests the 
byte-range lock request for conflict with existing CIFS and NLM byte-range locks. 

Upon receiving an NLM byte-range lock request message 140. the file server 110 tests 
the byte-range lock request for conflict with existing CIFS and NLM byte-range locks, 
and for conflict with existing CIFS file locks. 

Upon receiving an NLM file lock request message 140 from a PC NFS client device 130 
(used to simulate a file-open request message 140). the file server 1 10 tests the NLM file 
lock request for conflict with existing CIFS and NLM file locks, and for conflict with 
existing NLM byte-range locks. For the purpose of comparison with newly requested 
NLM file locks, the file server 1 10 treats existing NLM byte-range locks as having deny- 
n.ode deny-none, and as having access-mode read-only for nonexclusive locks and 
access-mode read-write for exclusive locks. 
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Method of Operation (Multi-Protocol File Server) 

Figure 3 shows a process flow diagram of a method of operating a multi-protocol 

file server. 

5 

A method 300 of operating a multi-protocol file server includes a set of process 
steps and flow points as described herein, to be performed by the file server 1 10 in cooperation 
with at least one client device 1 30. 

10 At a flow point 310, the file server 1 10 is ready to receive the file server request 

message 140, 

At a step 311, the file server 110 receives and parses the file server request 
message 140. The file server 110 determines if the file server request message 140 uses the NFS 
15 file server protocol, the NLM file locking protocoL or the CIFS file server protocol. If the file 
server request message 140 uses the NFS file server protocol or the NLM file locking protocol, 
the method 300 continues with the step 312. If the file server request message 140 uses the 
CIFS file server protocol, the method 300 continues with the step 313. 

20 At a step 312, the file server 1 10 determines if the request message 140 includes 

an NFS file server request to perform a file system operation (such as to read or write data, or to 
modify a directory). Alternatively, the file server 110 determines if the request message 140 
includes an NLM file-locking request to obtain an NLM byte-range lock. In either case, the 
method 300 continues at the flow point 320. 

25 

At a step 3 1 3, the file server 1 10 determines if the file server request message 140 
is to perform a CIFS read or write operation, to obtain a CIFS byte-range lock, or to perform a 
CIFS file-open operation. In the file server request message 140 is to obtain a CIFS byte-range 
lock or to perform a CIFS file-open operation, the method 300 continues at the flow-point 320. 
30 If the file server request message 140 is to perfonn a CIFS read or write operation, the method 
continues at the flow-point 330. If the file server request message 140 is a CIFS "change-notify" 
request, the method continues at the flow point 350 (the change-notify request is ftirther 
described with regard to figure 6). 

9 
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A, . flow point 320. the file server 110 U r^idy to eompare the opemtion 
requested by the fUe server request message 140 with the fiWoeking status of the fie 1 .3^ The 
me-lockiug status of the file 1 .3 iucludes exisUng file locks aul byte-range locks for the file 
113. 

At a step 321. the file server 1 10 d«ermmes the file 1 13 that Is the subject of the 
file server request message 140. and deunnines if U» file .13 is oplocked If the file 113 is 
oplooked, the method 300 corrtnues with the step 322. If the file 113 is no, oplocked, the 

method 300 continues with the step 323, 

At a step 322, the file server 110 breaks the oplock, as described herein. 
Performance of the step 322 is further described with regard to figure 5. Breakir^g the oplock 
can cause the file-locking status of the file 1 15 to change. 

At a step 323. the file server 1 10 compares the requested operation with the file- 
locking status of the file 113, using a uniform file-locking semantics. In this step, the requested 

. o« MF<; nr CIFS directory modificaUon 

operation can be an NFS read or wntc operahon, an NFS or CIFS du ry 

operation, an .»empt to obt»n an NLM file lock or byte-range lock, or a CIFS ftle^n 
oUo. P^fomance of the step 323 »d ^ unifom, file-lockmg sema.,.. s a^«>« 
.0 dLbed with regard to figure 4. ,f the compaHson shows d«. d,e requested o^t n 
aUowable. the n^thod 300 continues with the step 324. If dre requested operahon ,s 
allowable, the method 300 continues with the step 325. 

At a step 324, the file server 1 10 performs the requested operation. Tl.e method 

25 300 continues at the flow point 340. 

A. a step 325, the file server 1 10 refirses to perform the requested operadon and 
,«p„.ds to the client device 130 with an error message, m methc^ 300 contmues at the fiow 



point 340. 



At a flow point 330, the file server 110 is ready to compare the operation 
requested bythe file server request message 140 with the file-locking status ofthefilein. 

At a flow point 350, the file server 1 10 is ready to perform the change-notify 
35 operation, as described herein. 
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At a Step 351, a first CIFS client device 130 requests a file lock for a directory 
(using a file system request message 140 to open the directory), and converts the file lock for the 
directory to a change-monitoring lock on the directory. Performance of this step 351 is further 
described with regard to figure 6, 

At a flow point 340, the file server 1 10 has responded to the file server request 
message 140, and the method 300 is complete with regard to that file server request message 
140. 

Method of Operation (Cross-Protocol Lock Manager) 

Figure 4 shows a process flow diagram of a method of operating a cross-protocol 
lock manager in a multi-protocol file server. 

A method 400 of operating a cross-protocol lock manager in a multi-protocol file 
server includes a set of process steps and flow points as described herein, to be performed by the 
file server 1 10 in cooperation with at least one client device 130. 

At a flow point 410, the file server 110 is ready to compare the requested 
operation in the file server request message 140, with the file-locking status of the file 1 13. 

The file server 110 uses a uniform file-locking semantics, so as to model file- 
locking aspects of any requested operation from any file server protocol in the same way. The 
unifonn file-locking semantics identifies a uniform set of file locks, each including an access- 
mode for the requesting client device 130 and a deny-mode for all other client devices 130. 

In a preferred embodiment, the access-mode can be one of three possibilities- 
read-only, write-only, or read-write. Similarly, in a preferred embodiment, the deny-mode can 
be one of four possibilities— deny-none, deny-read, deny-write, or deny-all. 

After a first client device 130 obtains a file lock for a file 1 13, a second client 
device 130 can only access that file 1 13 if the lock mode determined by the file server 1 10 to be 
requested by the second client device 130 is compatible with the file-locking status of the file 
1 13. For example, a first client device 130 can obtain a file lock for a file 1 1 3 with a deny-mode 
deny-write. A second NFS client device 130 could attempt to write to the file 1 13, or a second 
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thP file 1 13 with an access-mode including write 

M „„^h..., .he m. s».e, no pe*,- — n of 0,. >»c>c«* 
0. ,=,ues.ed .He s^n. e„e„. device ,30 . d>«ertns .^e. .„ ^ » - 
server pio.ocol used by *e seeond clien. device 130: 

,r^seeo„deUe„.de.ee no .es.KeC.FS file server pro»colu,open d^f„eU3, .he 
f„eserver,.0cbecks*efi.e.,oetogsu.usof*efi.eU3a.«e.pen.me. 

. . . .1,. NF'! file server pioMcol M read or wriK .o die 
„ U„ second clieo. devce 130 uses «ie WS file s^n- P 

move, remove, or rename the file 113. 

r IF«; file server protocol to request a byte-range 
If the second client device 130 uses the CIFS file sen.e p 
,n.k the file server 1 10 checks the file-locking sutus of the file 113 tor 
2aZ 7.U byte-range locks, at the time the byte-range lock is requested. The 
° r:rnOdoesno:checkforconnictwUhotheraPSftlelocksatth^ 
^ge lock is requested, because those were checked at file-open ttme. 

. d client device 130 uses tl« NLM protocol to request a byte-range lock, the 
If the second client device i^u us 

file server 110 checks die file-loclcing SU.US of .he f""" 

CIFS or NLM by.e-«nge lodes, »d for conflic, v..h emung CIFS file loclcs. 

the byte-range lock is requested. 

•f ic alreadv more than one file 
A, a s.ep 421, d.e file serve, 1 10 d=.en..nes ,t4ere 
3, lock associa.edwld,*e file ,13. If so, d.e .nelhod 400 co«,nues v„d, d,e s.ep 42 

method continues with the step 41 1 . 

« a s.ep 422. the fl,e server „0 combines fi,e ,ocks already associa^d wld, U» 

■ , A ,;th the file 113 To perform this step 422, 
file 113 into a single equivalent file lock associated with the file 113. 
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the file server 1 10 cross-indexes in table 1 a cumulative file lock with each pre-existing file lock, 
until all pre-existing file locks have been cumulated together. 

Table 1 shows a lock conversion table in a multi-protocol file server with unified 
5 file-locking semantics. 



Existing file lock mode 



NULL 



A:R 


A: W 


A: RW 


A:R 


A: 


W 


A: RW 


A:R 


A: W 


A: RW 


D: DN 


D: DN 


D: DN 


D: DR 


D: 


DR 


D: DR 


D: DW 


D: DW 


D: DW 



A: Any 
D: DA 



NULL 



A:R 
D: DN 



A: W 
D: DN 



A: RW 
D:DN 



A:R 
D: DR 



A: W 
D: DR 



A: RW 
D: DR 



A: R 
D: DW 



A: W 
D: DW 



A: RW 
D: DW 



A: 

Any 

D:DA 



NULL 



A:R 
D: DN 

A: W 
D:DN 

A: RW 
D: DN 

A:R 
D; DR 

A: W 
D: DR 

A:RW 
D:DR 

A:R 
D: DW 

A: W 
D: DW 

A: RW 
D: DW 



A: Any 
D: DA 



A:R 
D: DN 

A:R 
D: DN 

A: RW 
D: DN 

A: RW 
D: DN 

A:R 
D: DR 

A: RW 
D: DR 

A: RW 
D: DR 

A:R 
D: DW 

A: RW 
D: DW 

A: RW 
D: DW 



A: Any 
D: DA 



A: W 
D: DN 

A: RW 
D: DN 

A: W 
D: DN 

A: RW 
D: DN 

A:RW 
D: DR 

A; W 
D: DR 



RW 
DR 



A: RW 
D: DW 

A: W 
D: DW 

A: RW 
D: DW 



A: Any 
D: DA 



A: RW 
D: DN 

A: RW 
D: DN 

A: RW 
D: DN 

A: RW 
D: DN 

A: RW 
D: DR 

A:RW 
D: DR 

A: RW 
D: DR 

A: RW 
D: DW 

A: RW 
D: DW 

A: RW 
D: DW 



A: Any 
D: DA 



A:R 
D: DR 

A:R 
D: DR 

A: RW 
D: DR 

A:RW 
D: DR 

A:R 
D: DR 

A:RW 
D: DR 

A:RW 
D: DR 

A: Any 
D: DA 

A: Any 
D: DA 

A: Any 
D: DA 

A: Any 
D: DA 



A: W 
D: DR 

A: RW 
D:DR 

A: W 
D: DR 

A: RW 
D: DR 

A: RW 
D: DR 

A: W 
D: DR 

A: RW 
D:DR 

A: Any 
D: DA 

A: Any 
D:DA 

A: Any 
D: DA 



A: Any 
D: DA 



A: RW 
D:DR 

A:RW 
D: DR 

A: RW 
D: DR 

A: RW 
D: DR 

A: RW 
D: DR 

A: RW 
D: DR 

A: RW 
D: DR 

A: Any 
D: DA 

A: Any 
D: DA 

A: Any 
D: DA 



A: Any 
D:DA 



A:R 
D: DW 

A:R 
D: DW 

A: RW 
D: DW 

A: RW 
D:DW 

A: Any 
D: DA 

A: Any 
D:DA 

A: Any 
D: DA 

A:R 
D: DW 

A; RW 
D: DW 

A: RW 
D: DW 



A: Any 
D: DA 



A: W 
D: DW 

A: RW 
D: DW 

A: W 
D: DW 

A: RW 
D: DW 

A: Any 
D: DA 

A: Any 
D: DA 

A: Any 
D: DA 

A: RW 
D: DW 

A: W 
D: DW 

A: RW 
D: DW 



A: Any 
D: DA 



A: RW 
D: DW 

A: RW 
D:DW 

A: RW 
D: DW 

A: RW 
D: DW 

A: Any 
D: DA 

A: Any 
D:DA 

A: Any 
D: DA 

A: RW 
D: DW 

A: RW 
D: DW 

A: RW 
D: DW 



A: Any 
D: DA 



A: Any 
D: DA 

A: Any 
D: DA 

A: Any 
D: DA 

A: Any 
D: DA 

A: Any 
D: DA 

A: Any 
D: DA 

A: Any 
D:DA 

A: Any 
D: DA 

A: Any 
D: DA 

A: Any 
D: DA 



A: Any 
D: DA 



10 



Table 1 

Lock Conversion Matrix 
A = Access Mode (R = Read, W = Write, RW = Read- Write, Any = any one of R or W or RW) 
D = Deny Mode (DN = Deny None, DR - Deny Read. DW = Deny Write, DA = Deny All) 
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At a step 41 1, the file server 1 10 determines the nature of the requested operation 
in the file server request message 140. If the requested operation is a CIFS file-open operation, 
the method 400 continues with the step 423. If the requested operation is an NFS file server 
operation, the method 400 continues with the step 431. If the requested operation is either a 
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CIFS request an NLM request for a byte-range lock, the file system 110 continues with the step 



441. 



At a step 423, the file server 1 10 compares the file lock already associated with 
the file 1 13 with the file open requested by the second client device 130. To perform this step 
423 the file server 1 10 cross-indexes in table 2 the pre-existing file lock and the requested new 
access-mode and deny-mode, and allows or denies the requested new access-mode and deny- 
mode in response to the associated table entry. 

If the file server 1 1 0 allows the requested new access-mode and deny-mode, the 
method 400 performs the step 424. If the file server 1 10 denies the requested new access-mode 
and deny-mode, the method 400 does not perform the step 424. 

Table 2 shows a cross-index ol attempted file locks in a multi-protocol file server 
with unified file-locking semantics. 
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Pre-existing file lock 








NULL 


A: R 
D: DN 


A: R 
D: DR 


A: R 
D: DW 


A: W 
D: DN 


A: W 
D: DR 


A: W 
D: DW 


A: RW 
D: DN 


A: RW 
D: DR 


A: RW 
D: DW 


A: Any 
D: DA 




NULL 


✓ 


✓ 


V 




_/ 










• ^ 


/ 




D: DN 






A 




V 


A 






Y 




Y 

A. 




A. K 

D: DR 




X 


X 


X 




X 






Y 
A 




Y 
A 


iquesi 


A • D 

A, K 
D: DW 






X 


V 


X 


X 


A 


Y 

A 


Y 
A 


Y 
A 


Y 
A 


ing re 


D: DN 




y 
V 




V 

A 




^ 


Y 
A 






Y 
yv 


Y 
A 


de be 


A: W 
D: DR 




X 


X 


X 


✓ 


>/ 


X 


X 


X 


X 


Y 


OUl M 


A: W 
D: DW 






^ 


X 


X 


X 


X 


X 


X 


X 


X 


Z 


A: RW 
D: DN 






X 


X 


✓ 


X 


X 


✓ 


X 


X 


X 




A: RW 
D: DR 




X 


X 


X 


✓ 


X 


X 


X 


X 


X 


X 




A: RW 
D: DW 






X 


X 


X 


X 


X 


X 


X 


X 


X 




A; Any 
D: DA 




X 


X 


X 


X 


X 


X 


X 


X 


X 


X 



Table 2 



Multi-Protocol Lock Compatibility Matrix 
A = Access Mode. D - Deny Mode 
^ = jsjew request will be granted. X = New request will be denied. 

5 

As shown in table 2, each pair of pre-existing file lock and requested new access- 
mode and deny-mode has an associated decision to allow or to deny the requested new access- 
mode and deny-mode. 

10 If the file server 1 10 is checking for conflicts between an existing CIFS file lock 

and a new request to perform a file-open operation, the existing CIFS file lock is cross-indexed 
against the access-mode and deny-mode requested in the new file-open request. 

If the file server 110 is checking for conflicts between existing file locks and a 
15 new NFS request to perform a file read or write operation, the aggregate lock mode (the 
. combination of existing file locks) is cross-indexed against the access-mode required to perform 
the new request. 

If the file server 1 10 is checking for conflicts between existing file locks or byte- 
20 range locks, and a new request for a NLM byte-range lock, the existing file locks and byte-range 

15 
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,<»ks cross-Wexed ^ a lock m«ie equivalent » *e new NLM by«-rang. lock «,u«^ 
F„, *c p^posc of oo« wid, cxis-ing flle locks. U,e ffl. s»v„ 1 10 newly «<,ues«d 
. NLM by.e.«nge locks as having denymode deny-none, and as having access-mod. «.d-o„^, 
for nonexclusive locks (^.o called "read locks") «,d access-mode read-write for -'-""f- 
(also called -wriie locks"). For ihe purpose of comparing wirh existfng by«-rang. locks, .he 61. 
server 1 10 treau newly r«,u.s.ed NLM byre-range locks as having access-mod. r.adK,nl, and 
deny-mode deny-wrire for read locks, and as having access-mode read-wri,. and deny-mode 
deny-all for write locks. 

) The method 400 then continues at the flow point 450. 

At a step 431, the file server 1 10 compares the file-locking status of the file 113 
with the operation requested by the second client device 130. To perform this step 431 the file 
server 110 compares the deny-mode for the file lock with the requested operation, and allows or 
5 denies the requested operation in response thereto. 

The method 400 then continues at Ihe How poim 450, 

At a step 441, the file serve, 110 compares the aie-lockmg status of th. f.lM13 
,0 with the NLM byte-range lock requested by ^e second client device 130. In a preferred 
.mbodim»t. CIFS bye-range lock reque«s are oMy chedced against byte-range locks ^e 
Urey require a prior CIFS file open operaUon a, which existrng We locks were already checked. 
Toperfom,.hisstep441,.heffleserver,10cross-indexes,n,able3th.pre-exis.mgf.le-l«.cm^ 

sul and the requested byt.-rang. lock, and allows or demes th. requ^tM byt^range lock m 

25 response to the associated table entry. 

If*. f,le server 1 10 allows the requested new NLM byte-range lock, dre m«hod 
400 ^orms dr. step 442. If the file se„er 1 10 denies the requested new byte-range lo* the 

method 400 does not perform the step 442. 

Table 3 shows a cross-index of existing file locks and newly requested NLM 
byte-range locks in a multi-protocol file server with unified file-locking semantics. 
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Existing lock mode 




None 


A:R 
D:DN 


A:R 
D: DR 


A:R 
D: DW 


j A: W 
1 D: DN 


A: W 
D: DR 


1 A: W 
1 D:DW 


A: RW 
D:DN 


A: RW 
D: DR 


A: RW 
D: DW 


A: Any 
D:DA 


Write 
Lock 








X 






X 




✓ 


X . 


X 


Read 
Lock 






X 






X 






X 




X 



Table 3 



Compatibility of new NLM byte-range locks with existing file locks 
A = Access Mode, D = Deny mode 
^ - New NLM byte-range lock request will be granted. 
5 X = New NLM byte-range lock request will be denied. 



As shown in table 3, each pair of existing file lock and newly requested NLM 
byte-range lock has an associated decision to allow or to deny the requested new byte-range 
lock. 

10 

At a step 442, the file server 1 10 associates the requested new byte-range lock 
with the file 1 1 3 as a new additional byte-range lock. 



The method 400 then continues at the flow point 450. 

15 

At a flow point 450, the file server 1 10 has compared the requested operation in 
the file server request message 140 with the file-locking status of the file 113, and allowed or 
denied the requested operation. 

20 Method of Operation (Oplock Manager) 

Figure 5 shows a process flow diagram of a method of operating an oplock 
manager in a multi-protocol file server. 

25 A method 500 of operating a oplock manager in a multi-protocol file server 

includes a set of process steps and flow points as described herein, to be performed by the file 
server 11 0 in cooperation with at least one client device 1 30. 

Oplocks are known in the art of file-locking in Windows operating system 
30 environments. They are further described in documentation available for the "Windows NT 4.0" 
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operating system, available from Microsoft Corporation of Redmond, Washington, including for 
example the CIFS IETF specification, available via the FTP protocol at host ftp.microsoft.com, 
directory /developr/drg/CIFS, files cifs6.doc or cifs6.txt, hereby incorporated by reference as if 
fiilly set forth herein. 

At a flow point 510, the file server 110 is ready to receive a request from a CIFS 
first client device 130 to open a file 113. 

At a step 51 1, the file server 1 1 0 receives a file-open request for a file 1 13 from a 
,0 CIFS first client device 130. The file-open request designates an access-mode and a deny-mode. 

At a step 5 12, the file server 1 10 determines that it should allow the request, and 
grants the first client device 130 a file lock with the designated access-mode and deny-mode. 

,5 At a step 513. if the client device 130 has requested an oplock on the file open 

request, the file server 1 10 grants the first client device 130 an oplock at a level of exclusivity 
possibly greater than the first client device 130 actually requires. 

For example, when a CIFS first client device 130 opens a file 113 with the 
20 access-mode read-only and deny-mode deny-write, the file server 1 10 associates a file lock of 
that type with the file 1 13. The file server 1 10 fiirther associates an oplock with the file 1 1 3 with 
the access-mode read-write and deny-mode deny-all. 

At a flow point 520, the file server 110 has responded to the request from the 
25 CIFS fu-st client device 130 for a file lock for a file 1 13. 



At a 



flow point 530. a second client device 130 attempts to open the file 113. 



30 



35 



At a Step 53 1 , the file server 1 1 0 receives either a file-open request from a second 
CIFS client device 130 or a NLM file lock request from a PC NFS client device 130. 

As part of performing this step 531, the file server 110 suspends execution of the 
request by the second client device 130 while it breaks the oplock and obtains a response from 
the holder of the oplock, the first client device 130. 
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At a step 532, the file server 1 10 breaks the oplock by sending an "oplock-break" 
message 1 40 to the CIFS first client device 130. 

When the second client device 130 is a CIFS client device 130, this is already 
5 expected. When the second client device 130 is an NFS client device 130, the file server 110 
delays its response to the NFS (or NLM) protocol request message 140 until the CIFS first client 
device 130 responds to the "oplock-break" message 140. 

At a step 533, the CIFS first client device 130 receives the "oplock-break" 
10 message 140, and can respond to the message 140 in one of two ways: 

o The CIFS first client device 130 can close the file 113 (thus removing the file lock 
associated with the file-open); or 

15 o The CIFS first client device 130 can flush all outstanding CIFS write and byte-range lock 
requests for the file 113 that are being cached locally at the client device 130 (that is, it 
can forward the results of those file system operations to the file server 110), and discard 
any read-ahead data it has obtained for the file 113. Read-ahead data should be discarded 
because the second client device 130 might subsequently write new data to the file, 

20 invalidating the read-ahead data. 

At a step 534, the file server 110 receives the response from the CIFS first client 

device 130. 

25 At a step 535, the file server 1 10 determines if the CIFS first client device 130 

has maintained the file 1 13 open, and if so, compares the lock mode implied by the request by 
the second client device 130 against the new file-locking status of the file 113. If the file server 
110 determines that the request by the second client device 130 is allowed to proceed, it 
continues with the flow point 540. If the file server 110 determines that the request by the 

30 second client device 1 30 is not allowed to proceed, it denies the request. 

At a flow point 540, the file server 1 10 is ready to proceed to allow the request 
from the second client device 1 30 noted in the step 53 1 . 

35 
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Method of Operation (Change-Notify Manager) 

Figure 6 shows a process flow diagram of a method of operating a change-notify 
manager in a multi-protocol file server. 

A method 600 of operating a change-notify manager in a multi-protocol file 
server includes a set of process steps and flow points as described herein, to be performed by the 
file server 1 10 in cooperation with at least one client device 130, 

At a flow point 610, the file server 1 10 is ready to receive the file server request 

message 140. 



At a step 61 1, the file server 410 receives a file-open request message 140 from a 
first CIFS client device 130, designating a directory on the file server 1 10. The file server 110 
15 detem^ines that it should allow the file-open request and grants a CIFS file lock on the directory 
to the first CIFS client device 130. 

At a step 612, the file server 1 10 receives a change-notify request message from 
the first CIFS client device 130, referencing the open directory, to convert the file lock on the 
20 open directory to a change-monitoring lock. 

At a step 613. the file server 1 10 converts the file lock on the open directory to a 
change-monitoring lock on the designated directory. 

25 At a flow point 620, the "change-monitoring" lock has been associated with the 

designated directory, and the first CIFS client device 130 is ready to be notified of changes to 
that directory. 

At a step 621, the file server 1 10 receives a file server request message 140 from 
30 a second client device 130. requesting a change to the designated directory, and thus triggering a 
.change notification to the first client device 130. (Types of change include file creation, file 
deletion, file rename, file move between directories, file attribute change, and file modification 
time change.) The file server request message 140 from the second client device 130 can be 
either CIFS or NFS. The second cUent device 130 can be any one of a Unix NFS client device 
35 201. a PC NFS client device 202, or a CIFS Windows client device 203. 
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At a step 622, the file server 1 10 notifies the first client device 130, which holds 
the "change-monitoring" lock, of the changes noted in the step 621, containing possibly multiple 
entries, each of which specifies both the name of the changed file 1 1 3 or subdirectory within the 
monitored directory and the type of change. If there is more than one such first client device 
5 1 30, the file server 1 1 0 notifies all of them. 

Change-notification is known in the art of file-locking in Windows NT operating 
system environments. It is further described in documentation available for the ^'Windows NT 
4.0" operating system, available from Microsoft Corporation of Redmond, Washington, 
10 including for example the CIFS IETF specification, available via the FTP protocol at host 
ftp.microsoft.com, directory /developr/drg/CIFS, files cifs6.doc or cifs6.txt, hereby incorporated 
by reference as if fiiUy set forth herein. 

At a flow point 630, the file server 1 10 has nofified the first CIFS client device 
15 130 of changes to the designated directory, and is ready for a next message 140. 

Alternative Embodiments 

20 Although preferred embodiments are disclosed herein, many variations are 

possible which remain v^thin the concept, scope, and spirit of the invention, and these variations 
would become clear to those skilled in the art after perusal of this application. 

Technical Appendix 

25 

Other and ftuther information about the invention is included in a technical 
appendix enclosed with this application. This technical appendix includes 30 pages (including 
drawings) and is hereby incorporated by reference as if fiilly set forth herein. 
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Claims 

1 A method of operating a file server, said method including steps for 
enforcing a uniform file-locking semantics among a set of client devices using a plurality of 
5 diverse file server or file locking protocols. 

2. A method as in claim 1, wherein said uniform file-locking semantics 

includes opportunistic locks capable of 

being requested by a first client device using a first protocol; and 
,0 breaking of said opportunistic locks being triggered by a second client device 

usmg a second protocol different fi-om said first protocol. 

3. A method as in claim 2. wherein said first protocol includes CIFS. 

4. A method as in claim 2. wherein said second protocol includes NFS or 



15 

NLM. 



20 



25 



5. A method as in claim I. wherein said uniform file-locking semantics 

includes Steps for ^ . - 

granting an opportunistic lock on a selected file to a first said client dev.ce m 

response to a first message using a first said protocol; and 

breaking said opportunistic lock in response to a second message using a second 

said protocol. 

6 A method as in claim 5. wherein said steps for breaking include steps for 
sending an oplock-break message to said first client device in response to said 
second message; 

delaying execution of a file system request indicated by said second message; 
receiving a response to said oplock-break message from said first client device; 

30 and ^ . . 

processing and responding to said second message after said step of recemng. 

7. A method as in claun 1, wherein said uniform file-locking semantics 

includes a change-monitoring lock type capable of 
35 being requested by a first cliem device using a first protocol; and 
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a change notification being triggered by a second client device using a second 
protocol different from said first protocol. 

8. A method as in claim 7. wherein said first protocol includes CIFS. 

5 

9. A method as in claim 7. wherein said second protocol includes NFS. 

10. A method as in claim 1, wherein said uniform file-locking semantics 
includes steps for 

10 granting a change-monitoring lock on a selected directory to a first said client 

device in response to a first message using a first said protocol; and 

sending a change-notify message to said first client device in response to a second 
message regarding said selected directory using a second said protocol. 

15 11 . A method as in claim 1 . wherein said steps for enforcing include steps for 

recognizing a plurality of diverse protocols; 

providing a uniform file-locking semantics in response to messages using at least 
one of said protocols; and 

enforcing said uniform file-locking semantics for all said client devices. 

20 

12. A method as in claim 11, wherein said uniform file-locking semantics 
includes steps for 

granting an opportunistic lock to a first said client device in response to a first 
message using a first said protocol; and 
25 breaking said opportunistic lock in response to a second message using a second 

said protocol. 

13. A method as in claini 12, wherein said steps for breaking include steps for 
sending an oplock-break message to said first client device in response to said 

30 second message; 

delaying execution of a file system request indicated by said second message; 
receiving a response to said oplock-break message from said first client device; 

and 

processing and responding to said second message after said step of receiving. 

35 
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14. A method as in claim 11, wherein said steps for enforcing said uniform 
file-locking semantics include steps for 

granting a change-monitoring lock in response to a first message firom a first 

client device xising a first said protocol; and 

sending a change-notify message to said first client device in response to a second 

message using a second said protocol. 

15. A method as in claim 11. wherein said steps for enforcing said uniform 

file-locking semantics include steps for 

recognizing a selected message that attempts to violate said uniform file-locking 

semantics; and 

responding to said selected message with an error response suited to a protocol 
associated with said selected message. 

16. A method as in claim 11, wherein said steps for enforcing said uniform 

file-locking semantics include steps for 

recognizing a selected message for obtaining a byte-range lock on a file in a 
selected said protocol, said byte-range lock having a lock type; and 

testing whether obtaining said byte-range lock would conflict with existing locks 
created by messages using the same or other protocols. 

17. A method as in claim 1 1, wherein said steps for enforcing said uniform 

file-locking semantics include steps for 

recognizing a selected message for opening a file in a selected said protocol, said 

selected message including a requested access-mode; and 

testing whether opening said file using said requested access-mode would conflict 
with existing locks created by messages using the same or other protocols. 

18. A method as in claim 1 7, 

wherein said selected message includes a requested deny-mode; and 
including steps for testing whether opening said file using said requested deny- 
mode would conflict with existing locks created by messages using the same or other protocols. 

19. A method as in claim 11, wherein said steps for enforcing said uniform 
file-locking semantics include steps for 
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recognizing a selected message for reading from or writing to a file in a selected 
said protocol; and 

testing whether reading from or writing to would conflict with existing locks 
created by messages using the same or other protocols. 

5 

20. A method as in claim 1 , wherein said steps for enforcing include steps for 
receiving a first message using a first protocol, said first message being operative 

to lock at least a portion of a selected file; 

receiving a second message using a second protocol, said second message being 
10 operative to request access to said portion; 

comparing said access requested by said second message with said lock, and 
denying said access if prohibited by said lock. 

21 . A method as in claim 20, wherein said first protocol includes CIFS. 

15 

22. A method as in claim 20, wherein said first protocol or said second 
protocol includes NLM. 

23. A method as in claim 20, wherein said second protocol includes NFS. 

20 

24. A method as in claim 20, wherein 

said steps for receiving said second message include steps for recognizing said 
second message as being for obtaining a byte-range lock on a file using said second protocol, 
said byte-range lock having a lock type; and 
25 said steps for comparing include steps for testing whether obtaining said byte- 

range lock having said lock type would conflict with existing locks created by messages using 
the same or other protocols. 

25. A method as in claim 24, wherein said steps for testing are responsive to a 
30 protocol used for said second message. 

26. A method as in claim 24, wherein said steps for testing operate at file- 
open time for a first said protocol and at an access time for a second said protocol. 
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27. A method as in claim 24, wherein said steps for testing operate at file- 
open time for a first said protocol and at a lock-request time for a second said protocol. 

28. A method as in claim 20, wherein 

said steps for receiving said second message include steps for recognizing said 
second message for opening a file using said second protocol, said second message including a 

requested access-mode; and 

said steps for comparing include steps for testing whether accessing said file 
using said requested access-mode would contlict with existing locks created by messages using 
the same or other protocols. 

29. A method as in claim 20, wherein 

said steps for receiving said second message include steps for recognizing said 
second message for reading from or writing to a file using said second protocol; and 

said steps for comparing include steps for testing whether accessing said file as 
attempted by said second message would confiict with existing locks created by messages using 
the same or other protocols. 

30. A method as in claim 20, wherein 

said steps for receiving said first message include steps for granting an 
opportunistic lock in response to said first message; and 

said steps for comparing include steps for breaking said opportunistic lock in 

response to said second message. 

31. A method as in claim 30, wherein said steps for breaking include steps for 
sending an oplock-break message to said first client device in response to said 

second message; 

delaying execution of a file system request indicated by said second message; 
receiving a response to said oplock-break message fiom said first client device; 

and 

processing and responding to said second message after said step of receiving. 

32. A method as in claim 31, wherein said response to said oplock-break 
message includes an oplock-break acknowledgement message or a file close message. 
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33. A method as in claim 1, wherein said file-locking semantics includes a 
lock mode determined in response to an access-mode and a deny-mode requested by a first client 
device using a first protocol. 

5 34. A method as in claim 1 . wherein said file-locking semantics includes 

a first lock mode determined in response to an access-mode and a deny-mode 
requested by a first client device using a first protocol; and 

a second lock mode determined in response to a message firom a second client 
device using a second protocol different from said first protocol; 
10 wherein said file server is responsive to comparison of said first lock mode with 

said second lock mode. 

35. A method as in claim 34, wherein said comparison includes a lock 
compatibility matrix. 

15 

36. A method as in claim 34, wherein said comparison includes a lock 
conversion matrix. 

37. A method as in claim 34, wherein said second lock mode is responsive to 
20 a request for a byte-range lock. 

38. A method as in claim 34, wherein said second lock mode is responsive to 
a request for a NLM file lock. 
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